…ror type (#4122)

## Summary

Addresses a Codex finding (relayed via the #4119 review):
`TbtcChain.GetWallet` derived a **legacy** wallet ID on **any** error
from the canonical `walletID` accessor. For a FROST wallet on a
canonical Bridge, a transient call failure would silently yield the
left-padded legacy ID — and callers use `WalletChainData.WalletID` to
choose **P2TR (FROST)** vs **P2WPKH (legacy)** scripts, so the node
would build or search the **wrong wallet script**.

## Why route by scheme (revised after Codex P1)

The first revision distinguished by error type (a sentinel for the
missing accessor, surface everything else). Codex correctly flagged a
**P1 regression**: a *legacy on-chain Bridge* built with the *current*
generated binding still satisfies the accessor interface, so its missing
`walletID` function returns a normal RPC/ABI error — not the sentinel —
and that revision would surface it and **break `GetWallet` on exactly
the legacy deployments the fallback exists for**. Error type cannot
reliably separate "function absent on-chain" from "transient."

So this routes by **scheme**, using the wallet's `EcdsaWalletID` (which
`GetWallet` already reads, and which the codebase already uses to infer
scheme — zero ⇒ FROST):

- **Legacy ECDSA wallet** (`EcdsaWalletID != 0`): its canonical wallet
ID *equals* its legacy derivation, so fall back on **any** accessor
error — and it's the only option on a legacy Bridge lacking the
accessor.
- **FROST wallet** (`EcdsaWalletID == 0`): requires the canonical ID;
**surface** the error rather than return a wrong legacy ID. A FROST
wallet only exists on a canonical-ID Bridge, so such an error is
genuinely transient.

Logic is extracted into `resolveWalletID(bridge, walletPublicKeyHash,
ecdsaWalletID)`.

## Tests

`TestResolveWalletID` covers all four cases: accessor success →
canonical; FROST + accessor error → surfaced; **legacy + accessor error
→ legacy fallback** (the P1 regression guard — verified to fail if the
routing surfaces errors for legacy wallets); legacy + missing-accessor
binding → legacy fallback. gofmt + `go vet` clean; full
`pkg/chain/ethereum` suite passes.

_Found during the Codex review batch on #4115–#4120; revised per the
Codex P1 re-review._

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

The native tbtc-signer Sign path scrubs its Go-heap FFI transport buffers
that carry secret material (via `defer zeroBytes(...)` on the request/
response/nonces slices), but the DKG path did not, leaving long-term
share and DKG secret material resident in the Go heap after use. This
closes that DKG<->Sign zeroization inconsistency.

The DKG engine methods build a Go-heap request payload (JSON), hand a C
copy to the Rust FFI via C.CBytes, and receive the response as a fresh
Go slice via C.GoBytes. callBuildTaggedTBTCSignerOperation already scrubs
and frees the C-heap request copy, and the Rust side frees the C response
buffer, but the Go-side request/response slices were never wiped. Mirror
the Sign path exactly by deferring zeroBytes on the secret-bearing Go
buffers, so a mid-function or error return still wipes:

- Part1: response (round-1 secret package / private polynomial coeffs).
- Part2: request (round-1 secret package) and response (round-2 secret
  package + per-recipient round-2 secret shares).
- Part3: request (round-2 secret package + received secret shares) and
  response (final key package / long-term signing share).
- RunDKGWithSeed: request (DKG seed that deterministically reconstructs
  the group secret); its response is public metadata only.

Public-only buffers are left untouched (RunDKG request/response, Part1
request). The defers run after the decoders evaluate the return value,
and the decoders return freshly hex-decoded copies, so wiping the
transport buffers never corrupts the returned secrets. cgo-safe: the
Go slices are independent of the C copies, so zeroing them after the
call returns neither races the C side nor risks a double-free.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The interactive FROST + ROAST retry coordinator flow (liveness +
evidence/blame) lives behind the `frost_roast_retry` build tag, but no CI
job ever set it: client.yml and release.yml run untagged `go build/test`,
and frost-cgo-integration.yml built only `frost_native frost_tbtc_signer`
and `-run`-filtered to the `TestRealCgoInteractiveSigning*` family. So the
entire ROAST retry state machine and ~30 `frost_native` unit tests never
compiled or ran in CI, and `make build` (the release/Docker path) shipped
the `!frost_roast_retry` no-op stubs. This closes that activation gap.

- client.yml: add a `client-frost-roast-retry` job that builds the
  coordinator path with cgo disabled (`go build -tags "frost_roast_retry"`
  and `-tags "frost_native frost_roast_retry"` over `./...`) and runs the
  tagged unit tests under the three non-cgo tag sets that cover the whole
  matrix (`frost_native`, `frost_roast_retry`,
  `frost_native frost_roast_retry`) over ./pkg/frost/... and ./pkg/tbtc/...
  against the mock FFI (no Rust lib, no Docker).

- frost-cgo-integration.yml: add `frost_roast_retry` to the real-crypto
  cgo tag set and drop the narrow `-run` filter so the whole tagged
  pkg/frost/signing suite runs against the linked libfrost_tbtc (skips
  still forbidden); the heavy multiproc e2e tests already ran and
  self-constrain their worker subprocesses with anchored `-test.run`, so
  dropping the outer filter only adds lighter tagged unit tests. Add a
  step that smoke-builds the activation artifact via `make build-frost`.

- Makefile: add a `build-frost` target that produces the ROAST-retry
  activation binary (tags `frost_native frost_tbtc_signer
  frost_roast_retry`, cgo-linked to libfrost_tbtc with the same
  CGO_LDFLAGS as the cgo workflow).

- frost-roast-retry-rollout.adoc: replace the false claim that CI already
  exercised the tag with an accurate description of the new coverage.

Locally validated (system Go, cgo off): `go build -tags "frost_roast_retry"
./...` and `-tags "frost_native frost_roast_retry" ./...` compile clean;
all three non-cgo tag sets pass on ./pkg/frost/... and ./pkg/tbtc/...
The cgo-linked full build is deferred to CI (requires building the Rust
libfrost_tbtc, which the cgo workflow does from the pinned signer source).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…th) (#4128)

## Finding

The native tbtc-signer **Sign** path scrubs its Go-heap FFI transport
buffers that carry secret material — `defer zeroBytes(...)` on the
request payload, response payload, and nonces slices
(`native_frost_engine_tbtc_signer_registration_frost_native.go`). The
**DKG** path in the same file did **not**, leaving long-term share / DKG
secret material resident in the Go heap after use. This is a
memory-hygiene inconsistency: DKG secrets (private polynomial
coefficients, per-recipient secret shares, and the final long-term
signing share) linger in reclaimable-but-unwiped Go heap buffers,
whereas the equivalent Sign secrets are wiped.

## Sites zeroed

Each DKG engine method marshals a Go-heap JSON request, hands a **copy**
to Rust via `C.CBytes`, and receives the response as a **fresh** Go
slice via `C.GoBytes`. Only the genuinely secret-bearing Go-side buffers
are wiped (public-only buffers are left untouched):

| Method | Buffer | Secret it carries |
| --- | --- | --- |
| `Part1` (`~L718`) | response | round-1 secret package (private
polynomial coefficients, "must never be broadcast") |
| `Part2` (`~L737`) | request | round-1 secret package |
| `Part2` (`~L746`) | response | round-2 secret package + per-recipient
round-2 secret shares |
| `Part3` (`~L768`) | request | round-2 secret package + received
round-2 secret shares |
| `Part3` (`~L777`) | response | final key package (long-term signing
share) |
| `RunDKGWithSeed` (`~L686`) | request | DKG seed that deterministically
reconstructs the group secret |

Left untouched because they carry no secret: `RunDKG` request/response
(participant public keys + metadata), `RunDKGWithSeed` response (public
metadata only), `Part1` request (participant id + signer counts).

## How it mirrors the Sign path

The Sign path uses the package-local `zeroBytes(data []byte)` helper
(`native_frost_engine_frost_native.go:59`) via `defer`:
- `GenerateNoncesAndCommitments`: `defer zeroBytes(responsePayload)`
(response carries one-time nonces).
- `Sign`: `defer zeroBytes(noncesData)` and `defer
zeroBytes(requestPayload)`.

This change reuses the same helper and the same `defer` placement (right
after a secret request is built / a secret response is received), so a
mid-function or error return still wipes. No new/divergent mechanism is
introduced.

## cgo-safety reasoning

- `callBuildTaggedTBTCSignerOperation` already `C.CBytes`-copies the
request to the C heap and, on defer, `zeroBytes`+`C.free`s that C copy.
The Go-side request slice is a **separate** `json.Marshal` allocation,
so zeroing it after the call returns neither races the C side nor risks
a double-free.
- The response is a `C.GoBytes` copy; the C-side response buffer is
freed separately by `tbtc_signer_free_buffer`. Wiping the Go copy is
independent and safe.
- The deferred `zeroBytes` runs **after** the decoder evaluates the
return value, and the decoders return freshly hex-decoded copies
(independent of the transport buffer), so wiping never corrupts the
returned secret. Identical ordering to the existing
`GenerateNoncesAndCommitments`.

## Validation

- `gofmt -l` clean on the touched file.
- `go vet -tags "frost_native frost_tbtc_signer" ./pkg/frost/signing/`
clean.
- `go build -tags "frost_native frost_tbtc_signer" ./pkg/frost/...`
succeeds (cgo path uses runtime `dlopen`, so it compiles the touched
file without the Rust lib present).
- `go build -tags "frost_roast_retry" ./pkg/frost/...` succeeds (non-cgo
compile check).
- DKG/RunDKG/Sign/Nonces unit tests pass.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

…#4130)

## Why

This closes the **sole production-activation blocker** found in the deep
production-readiness review of the ROAST retry work (stacked on #3866).

The interactive FROST + ROAST retry coordinator flow — `BeginAttempt` /
`RecordEvidence` / `AggregateBundle` / `VerifyBundle` / `NextAttempt`,
i.e. liveness plus slashing/blame — lives behind the `frost_roast_retry`
Go build tag (~50 files). **No CI job ever set that tag:**

- `client.yml` (~line 138) and `release.yml` (~line 56) run untagged `go
build/test ./...`, which compiles only the `!frost_roast_retry` no-op
stubs.
- `frost-cgo-integration.yml` (~line 111) built only `-tags
"frost_native frost_tbtc_signer"` and `-run`-filtered to the
`TestRealCgoInteractiveSigning*` family.

Net effect: the entire ROAST retry state machine and ~30 `frost_native`
unit tests never compiled or ran anywhere in CI, and `make build` (the
release/Docker path) shipped the ROAST-retry-noop default build. The
rollout doc also **falsely** claimed CI already exercised the tag.

## What this changes

**`.github/workflows/client.yml` — new `client-frost-roast-retry` job**
(plain Go, cgo off, no Docker; runs on every PR touching Go):
- `go build -tags "frost_roast_retry" ./...` and `go build -tags
"frost_native frost_roast_retry" ./...` (mock-FFI, no Rust lib).
- `go test` under the **three non-cgo tag sets that cover the whole
matrix** — `frost_native`, `frost_roast_retry`, `frost_native
frost_roast_retry` — over `./pkg/frost/...` and `./pkg/tbtc/...`.

**`.github/workflows/frost-cgo-integration.yml`:**
- Adds `frost_roast_retry` to the real-crypto cgo tag set (`frost_native
frost_tbtc_signer frost_roast_retry`).
- **Drops the narrow `-run` filter** so the whole tagged
`./pkg/frost/signing/` suite runs against the linked `libfrost_tbtc`,
with skips still forbidden (`KEEP_CORE_FROST_REQUIRE_CGO=true`). Safe by
construction: the heavy multiproc e2e tests already ran (matched by the
old substring regex) and spawn their worker subprocesses with anchored
`-test.run`, so dropping the outer filter only *adds* lighter tagged
unit tests.
- New step smoke-builds the activation artifact via `make build-frost`
using the lib built earlier in the job.
- Adds `Makefile` to the path triggers.

**`Makefile` — new `build-frost` target:** produces the ROAST-retry
activation binary (tags `frost_native frost_tbtc_signer
frost_roast_retry`, cgo-linked to `libfrost_tbtc` with the same
`CGO_LDFLAGS` as the cgo workflow). The default `make build` still ships
the `!frost_roast_retry` stubs; adopting the tagged artifact in the
release/Docker path is gated on the readiness-manifest flip and is
intentionally left to that decision (the Rust lib currently lives on a
separate branch — see `ci/frost-signer-pin.env`), so this PR makes the
artifact *producible + CI-validated* rather than silently flipping the
default release image.

**`docs/development/frost-roast-retry-rollout.adoc`:** replaces the
false "CI already exercises the tag" claim with an accurate description
of the coverage above.

## Validated locally (system Go, cgo disabled)

| Check | Result |
| --- | --- |
| `go build -tags "frost_roast_retry" ./...` | compiles clean |
| `go build -tags "frost_native frost_roast_retry" ./...` | compiles
clean |
| `go test -tags "frost_native" ./pkg/frost/... ./pkg/tbtc/...` | pass |
| `go test -tags "frost_roast_retry" ./pkg/frost/... ./pkg/tbtc/...` |
pass |
| `go test -tags "frost_native frost_roast_retry" ./pkg/frost/...
./pkg/tbtc/...` | pass |
| `make -n build-frost` | expands correctly |

The tagged builds compiled clean and every newly-run non-cgo tagged test
**passed** — no failures were surfaced, and no assertion was weakened.

**Deferred to CI:** the cgo-linked full build/tests and the `make
build-frost` smoke — these require building the Rust `libfrost_tbtc`,
which cannot be done locally without the pinned signer source. The cgo
job already builds that lib, so those steps are correct by construction
(they reuse the same lib + `CGO_LDFLAGS`).

## Follow-ups / known gaps

- **cgo path is CI-only-validated.** The `frost_native frost_tbtc_signer
frost_roast_retry` real-crypto suite and `make build-frost` link
`libfrost_tbtc`; they were not run on this machine. First green run of
`frost-cgo-integration.yml` on this branch is the confirmation.
- **Release/Docker still ship the stub build by design.** `make build`
(Dockerfile `build-docker` stage) is unchanged; wiring `build-frost`
into the release image is deferred to the readiness-manifest flip and to
the branch merge that brings the signer crate in-tree (per
`ci/frost-signer-pin.env`).
- **pkg/tbtc cgo-tagged tests** (the 1–2 `frost_native frost_tbtc_signer
cgo` files, e.g. real taproot-tx build) are not yet in the cgo gate; the
cgo job keeps its `pkg/frost/signing` scope. Adding `./pkg/tbtc/` to the
cgo run is a reasonable next step but pulls the heavy tbtc suite under
real-crypto linking, so it is left as a follow-up.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Chain the full FROST wallet-creation coordinator↔chain flow into ONE
in-process run: a local FrostDKGChain emits FrostDKGStarted, the
coordinator's OnFrostDKGStarted subscription handles it (dedup, block
confirmation, DKG-state check, past-event lookup, group-membership
resolution), executeFrostDKGIfPossible announces readiness and runs the
REAL cgo tbtc-signer DKG, and the assembled result is submitted back
through SubmitFrostDKGResult, after which the wallet is verified
registered on the chain.

Previously the coordinator↔chain wiring and the real cgo DKG execution
were covered separately (frost_dkg_coordinator_test.go with stub results;
frost_dkg_execution_frost_native_test.go in isolation) and never in one
flow.

The DKG output is real: a thin recording wrapper delegates to the cgo
engine and captures the x-only group key, which the test asserts equals
the key submitted on-chain byte-for-byte (no injected/fake result can
pass), is a valid secp256k1 point, and backs a registered wallet. The
group is reduced to 3 seats held by one node because the cgo engine is a
process-global OnceLock<Mutex> and its development dealer DKG holds all
key packages in one engine (n>=2; the library rejects n==1). Gated
frost_native && frost_tbtc_signer && cgo, so plain frost_native builds
are unaffected.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

P1: probe the real linked libfrost_tbtc up front. The build-tagged
tbtc-signer engine registers whether or not the lib is linked, so the
prior availability check passed even with an absent/stale lib and the
missing ABI only surfaced inside the coordinator goroutine's
RunDKGWithSeed, making the test hang until the 90s deadline instead of
skipping. Now exercise the once-per-process ABI preflight up front via a
raw seeded RunDKGWithSeed and route the result through a helper mirroring
the reference skipFrostUnavailable: ErrNativeCryptographyUnavailable SKIPS
(or FATALs under KEEP_CORE_FROST_REQUIRE_CGO), any other error fails. The
probe runs on the raw engine so it never pollutes the recording wrapper's
captured key.

P2: remove the recovery-goroutine race. initializeFrostDKGCoordinator also
launches recoverFrostDKGCoordinatorState; if it observed AwaitingResult
before the OnFrostDKGStarted subscription, it could drive the DKG via the
waitForConfirmation=false bypass and the deduplicator would suppress the
subscription path, passing the test without exercising the confirmation
flow. The chain now signals when recovery has completed its initial IDLE
scan (the first GetFrostDKGState reader), and the test waits for that
signal before flipping to AwaitingResult+emitting - so only the
subscription's block-confirmation path can run. A deterministic assertion
(submit block >= emit block + dkgStartedConfirmationBlocks) proves the
confirmation waitForBlockHeight path was exercised and guards against
silent regression.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

## What this adds

An in-process integration test that chains the **full FROST
wallet-creation
coordinator↔chain flow into ONE run**:

```
local chain emits FrostDKGStarted
  → initializeFrostDKGCoordinator's OnFrostDKGStarted subscription fires
    → handleFrostDKGStarted (dedup → confirm block → GetFrostDKGState →
       PastFrostDKGStartedEvents → resolve group membership)
      → executeFrostDKGIfPossible (readiness announcement → REAL cgo DKG via
         executeFrostDKG/RunDKGWithSeed → signer registration → result assembly
         → DKG-result operator-signature collection)
        → SubmitFrostDKGResult (through the FrostDKGChain interface)
          → wallet verified registered on the local chain
```

New file:
`pkg/tbtc/frost_dkg_coordinator_chain_e2e_frost_native_test.go`
(build-gated `frost_native && frost_tbtc_signer && cgo`).

## Why

Today the coordinator↔chain wiring and the real cgo DKG execution are
tested
**separately** and never in one flow:

- `frost_dkg_coordinator_test.go` drives the chain plumbing with stub
results.
- `frost_dkg_execution_frost_native_test.go` drives the real DKG in
isolation.

This closes that gap: event delivery, confirmation, membership
resolution,
readiness announcement, result assembly/signature collection, on-chain
submission, and wallet registration all run together against a real cgo
DKG
output.

## What is REAL vs REDUCED

**Real**
- **The DKG output.** `executeFrostDKG` calls the process-global cgo
  tbtc-signer engine (`buildTaggedTBTCSignerEngine`, registered via
`RegisterNativeExecutionFFISigningPrimitiveForBuild`). The x-only group
key
  that lands on-chain is the exact key the engine produced.
- **The submission path.** The result is submitted through the
`FrostDKGChain`
interface (`SubmitFrostDKGResult`) — not injected into chain state
directly.
- **The coordinator wiring.** The event is delivered through the
  `OnFrostDKGStarted` subscription registered by
`initializeFrostDKGCoordinator`; confirmation, state check, past-event
lookup,
membership resolution, readiness announcement, DKG-result
operator-signature
  collection, and delayed submission all run as in production.

**Reduced (documented)**
- **Group size / custody.** The group is a 3-seat group whose 3 seats
are all
  held by ONE operator/node. The cgo engine is a process-global
`OnceLock<Mutex>`, so N independent real-custody participants cannot run
concurrently in one OS process. The tbtc-signer **development dealer
DKG** by
design has a single engine hold every participant's key package — which
is
  exactly this shape. The cgo library rejects `n == 1`
(`participants must contain at least 2 entries`), so the minimum honest
  reduction is `n >= 2`; the test uses `GroupSize=3, GroupQuorum=2,
  HonestThreshold=2`.
- **Signer profile.** The test sets `TBTC_SIGNER_PROFILE=development`
(plus a
hermetic state-encryption key + per-process state path, mirroring the
existing
real-cgo reference harness). Bootstrap/dealer DKG is disabled under the
production profile, which requires distributed DKG wiring across
processes.

Nothing about the crypto or the submission is faked: the DKG output
comes from
the real engine and the submission goes through the chain interface.

## Load-bearing assertion

A thin recording wrapper delegates every engine method to the real cgo
engine
and captures the exact x-only key returned by `RunDKGWithSeed`. The test
then
asserts the on-chain submitted `Result.XOnlyOutputKey`:

1. **equals the captured real engine output byte-for-byte** (so no
injected /
   fake result can pass),
2. is non-zero and lifts to a valid secp256k1 curve point, and
3. the wallet derived from it is registered on the local chain
   (`IsFrostWalletRegistered`).

## How to run

```
export FROST_LIB_DIR=<path to libfrost_tbtc dir>
export CGO_ENABLED=1
export CGO_LDFLAGS="-L${FROST_LIB_DIR} -Wl,-rpath,${FROST_LIB_DIR} -lfrost_tbtc"
export KEEP_CORE_FROST_REQUIRE_CGO=true
go test -tags "frost_native frost_tbtc_signer cgo" -count=1 -v \
  -run 'TestFrostDKGCoordinatorChainEndToEnd_RealCgo' ./pkg/tbtc/
```

Proof lines from a passing run:

```
STEP 2: emitting FrostDKGStarted seed=0x42ef0705...
STEP 3+4: chain received SubmitFrostDKGResult x-only=3971f8481d56...d03d wallet=00...453a
STEP 4: SubmitFrostDKGResult observed on-chain
LOAD-BEARING: real cgo DKG x-only key 3971f8481d56...d03d landed on-chain via the coordinator
STEP 5: wallet 00...453a registered on-chain
--- PASS: TestFrostDKGCoordinatorChainEndToEnd_RealCgo
```

Without the cgo lib linked the test skips (or fails when
`KEEP_CORE_FROST_REQUIRE_CGO=true`), so it stays inert where real crypto
is
unavailable. It is excluded from the plain `frost_native` build, so the
existing
coordinator tests are unaffected (`go test -tags frost_native
./pkg/tbtc/`
stays green).

## Not covered / follow-up

This is an **in-process** rehearsal with one node holding all seats. It
does NOT
cover the fully-live path:

- **N distinct node processes** each holding real per-seat custody,
running the
**production distributed DKG** (not the development dealer DKG), which
is what
  `TBTC_SIGNER_PROFILE=production` requires.
- A **real chain** (hardhat / Ethereum) with **staked operators and
sortition**
  emitting `DkgStarted`, real `SelectFrostGroup`, and on-chain result
validation / challenge / approve, instead of the test-local
`FrostDKGChain`.
- **DKG-result signature collection across multiple operators** over a
live
network (here a single operator's signature satisfies the reduced
group's
  threshold with no network round-trip).

Those belong in a multi-process / system-test rehearsal and are out of
scope for
this in-process integration test.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

…kend

A node that participates in FROST DKG will also sign for the wallets it helps
create. Native FROST wallets carry native signer material that the transitional
legacy signing backend cannot process, so a node left on the default/legacy
backend produces valid wallets via DKG but then fails every signing attempt
(heartbeat, deposit sweep, redemption). DKG uses the native path directly, so
wallet creation succeeds and masks the misconfiguration until the first
signature.

Fail fast at startup: when FROST DKG is enabled but the signing backend is
legacy, return a clear error pointing at tbtc.frostSigningBackend (set it to
"native" or "ffi"). The native backend handles both native FROST and
legacy-ECDSA material, so it is always correct once FROST is enabled.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

… enabled

The normal Ethereum TbtcChain satisfies FrostDKGChain even when no FROST wallet
registry is configured, so the previous guard rejected the default legacy
backend on ordinary non-FROST nodes and broke their startup.

Gate the check on frostChain.FrostWalletRegistryAvailable() - the same signal
initializeFrostDKGCoordinator uses to no-op when FROST is disabled. The helper
now takes a frostEnabled bool and returns nil when FROST is off. Adds a test
case covering the FROST-disabled path.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

…on-legacy backend name

The fallback-allowed "native" mode selects a native backend name without
verifying that native execution is actually available (only strict "ffi" mode
checks). A FROST node on "native" with an unavailable native engine therefore
passed the guard, then fell back to the legacy bridge and failed on native FROST
signer material at signing time instead of startup.

Add signing.NativeExecutionAvailable() (mirrors the strict-mode availability
gate but is consultable in any mode) and require it in the guard in addition to
the non-legacy backend check. Adds a test with an adapter that reports native
execution unavailable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

…llback availability

NativeExecutionAvailable delegated to the build-tagged adapter's
NativeExecutionAvailable, which in fallback-allowed ("native") mode reports
available whenever the legacy delegate is present - even on a frost_native build
where the native tbtc-signer FFI engine failed to register or is not linked. The
guard could therefore accept native/ffi and let the node start, only to fall
back to legacy (or return ErrNativeCryptographyUnavailable) when signing
DKG-persisted FROST wallets.

Check currentNativeExecutionFFIExecutor() != nil instead - the same strict path
the native bridge uses (currentFFIExecutor() != nil) - so a FROST-enabled node
without a real native engine fails fast at startup. Test now registers a native
FFI executor for the accepted case and omits it for the rejected case.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

…transitional FFI wrapper

On a frost_native build not linked with the native signer (frost_tbtc_signer/cgo),
the build init still registers the transitional NativeExecutionFFIExecutor
wrapper, so currentNativeExecutionFFIExecutor() != nil returned true even with no
real tbtc-signer engine present. A FROST-enabled node on native/ffi then passed
the guard and started, only to fall back to legacy (or hit
ErrNativeCryptographyUnavailable) on DKG-persisted FROST signer material.

NativeExecutionAvailable now checks the actual linked signer engine via a
build-tag-split helper: currentNativeTBTCSignerEngine() != nil on frost_native
builds (the engine is registered only by frost_native && frost_tbtc_signer && cgo
- the same engine the transitional primitive requires before executing
natively), and false on non-frost_native builds. Adds a signing-package test for
NativeExecutionAvailable and a guard test for native-without-a-linked-engine.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

…gning available

The build-tagged buildTaggedTBTCSignerEngine wrapper is registered even when
libfrost_tbtc is not actually loaded or lacks the required ABI symbol - it only
discovers that later via dlsym/ABI preflight when an operation runs. So
currentNativeTBTCSignerEngine() != nil alone still let the FROST startup guard
pass on a frost_native && frost_tbtc_signer && cgo build with an absent/incompatible
library, and the node would start only to fail DKG/signing at runtime.

nativeSignerEngineAvailable now also requires ensureTBTCSignerABICompatible() == nil
- the same cached dlsym probe of frost_tbtc_abi_version the wrapper uses at
operation time, which returns nil only for a present, ABI-compatible library.
Split into build-tag variants: signer (engine registered AND ABI probe passes),
no-signer frost_native (false), and non-frost_native (false). Adds a test for the
engine-registered-but-ABI-probe-fails path via the tbtcSignerABI test hook.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

…assertions in optional-link profile

Two review follow-ups:

- The guard ran after node.runCoordinationLayer(ctx), so an invalid FROST backend
  started the coordination-window watcher and result processor before Initialize
  returned the error - a caller that did not immediately cancel the context could
  keep doing protocol work with a bad backend. Move the check before the
  coordination layer starts so the fail-closed path has no protocol side effects.

- The native-availability tests asserted NativeExecutionAvailable()/guard-accepts
  in the optional-link dev profile (frost_native frost_tbtc_signer cgo tags
  compiled without linking libfrost_tbtc via dlsym), where the ABI probe correctly
  reports unavailable - failing `go test` unless CGO_LDFLAGS provided the signer
  library. Skip the positive subtests when the ABI probe reports unavailable, in
  both pkg/frost/signing and the pkg/tbtc guard test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

…ams pool starts

The guard previously ran in Initialize after newNode returned. newNode, with the
default PreParamsPoolSize > 0 and legacy ECDSA not disabled, constructs the legacy
DKG executor (newDkgExecutor) which starts a pre-params pool scheduling CPU-heavy
generation/persistence on a background context. So an invalid FROST backend failed
Initialize while that background work kept running.

Move the check into newNode, right after configureFrostSigningBackend configures
the backend and before newDkgExecutor starts the pre-params pool, so the
fail-closed path has no pre-params (or later coordination) side effects.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

…kend (#4133)

## Problem

A node that participates in FROST DKG will also sign for the wallets it
helps create. Native FROST wallets carry native signer material
(`*signing.NativeSignerMaterial`) that the transitional **legacy**
signing backend cannot process.

The backend is selected by `tbtc.frostSigningBackend` (default:
`legacy`). Because DKG uses the native path directly, a node left on the
default/legacy backend **creates wallets successfully** but then **fails
every signing attempt**:

```
legacy signing material has wrong type: [*signing.NativeSignerMaterial]
```

This silent, delayed failure was hit during a live end-to-end FROST
rehearsal — DKG succeeded and the wallet registered, but every heartbeat
signature failed until `tbtc.frostSigningBackend=native` was set.

## Fix

Fail fast at startup: when FROST DKG is enabled but the signing backend
is `legacy`, return a clear error pointing at `tbtc.frostSigningBackend`
(set it to `native` or `ffi`). The `native` backend handles both native
FROST and legacy-ECDSA material, so it is always correct once FROST is
enabled.

## Test

`TestVerifyFrostSigningBackendForFrost` — legacy rejected, native
accepted.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01NuK4nVVvZQSgvBWsjQpuLN

First test to combine REAL threshold crypto + an induced signer failure + a
retry. Prior coverage was disjoint: the real-cgo interactive e2es are happy-path
only, and the ROAST retry/parking machinery (next_attempt.go) is unit-tested with
fakes; nothing wired them together.

roast_runner_real_cgo_dropout_retry_frost_native_test.go drives, end to end over
the real pkg/net transport against the real cgo FROST engine:
  attempt 1  - a SELECTED signer withholds its round-2 share; the elected
               coordinator (aggregator) starves and fails on a real collect-shares
               timeout;
  NextAttempt - the silent seat is absent from the transition bundle senders, so
               the real policy transiently PARKS it (excluded from attempt 2);
  attempt 2  - the reshuffled subset {coordinator, offline} aggregates a real
               BIP-340 signature and reaches Succeeded.

Determinism in the single-process shared-engine harness (first-come-first-served
subset selection, one shared engine): attempt 1 runs only {coordinator, target}
so the target is necessarily the co-signer, and the assertion is on the
coordinator's failure (a co-resident target may aggregate off the shared engine
- a harness artifact, not a real outcome). Build tags: frost_native
frost_tbtc_signer cgo.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…on (retry #2)

Second real-crypto-under-failure ROAST test. The real engine's share
verification and the f+1 reject-blame exclusion policy (next_attempt.go) were
only ever exercised separately (the policy with fakes); this wires them together.

roast_runner_real_cgo_invalid_share_exclusion_frost_native_test.go drives:
  attempt 1  - a selected signer submits a structurally valid but cryptographically
               WRONG round-2 share (corruptingRound2Engine mangles the engine's
               share output); the coordinator's REAL aggregate fails with a typed
               share-verification error that NAMES the culprit;
  NextAttempt - an ExclusionAccuserQuorum (f+1) reject quorum against the culprit
               PERMANENTLY excludes it (ExcludedSet, not a transient park);
  attempt 2  - the surviving subset aggregates a real BIP-340 signature without it.

Companion to the dropout/transient-park test (retry #1): same deterministic
{coordinator, target}-only attempt 1, but the invalid share yields exclusion
rather than parking. Build tags: frost_native frost_tbtc_signer cgo.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Review: the dropout test waited for the target runner but never checked its
outcome, so an EARLY target failure (undelivered signing package, or an engine
error before InteractiveRound2) would starve the coordinator identically and the
test would still pass -- without exercising the selected-signer-withheld-share
path it exists to cover.

Now assert, before driving the retry:
- the coordinator fails SPECIFICALLY at 'collect shares' (it built + broadcast the
  package, produced its own share, then starved on the target's) -- not a generic
  early error;
- the target REACHED round 2 and produced the share it withheld. Only the target's
  OUTBOUND share is dropped, so it still receives the coordinator's share and
  aggregates locally off the shared engine; that local success (sigLen 64,
  deterministic across runs) is the proof it produced -- and the bus withheld -- a
  genuine round-2 share. A pre-round-2 failure now fails the test.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…cation (retry #3b)

A selected signer runs round 2, produces a genuine FROST share, then broadcasts
two body-different signed share submissions for the same attempt (its real share
and a re-signed copy with a mutated signature_share). Both name the elected
coordinator and bind the authoritative signing package, so both are accepted
aggregation shares -- a second accepted-but-different signed body is member
double-signing. An honest Round2Collector fed the coordinator's authoritative
package and both shares flags the second as EquivocationKindShareConflict
(ErrShareConflict) and the process-wide observer receives the culprit-naming
evidence.

Closes the gap where the collector's conflict detection was only ever exercised
with synthetic submissions and fakes, never over a genuine engine-produced FROST
share submitted through the real transport. Detection is deterministic: the test
drives an independent honest collector with the exact on-wire envelopes the
Byzantine seat broadcast, decoupling detection from the runner's collect-shares
drain race. Asserts the fault was actually reached -- a real round-2 share was
produced and broadcast, and the two envelopes are distinct, same-package-bound
accepted shares (a genuine double-sign, not a divergent share).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…exclusion (retry #3a)

The elected coordinator distributes two VALID, coordinator-signed signing
packages for the same attempt with different bytes (distinct taproot roots).
Two authentic bodies signed by the coordinator's own operator key are
unforgeable proof, so verifiedCoordinatorEquivocations bypasses the f+1 accuser
gate and forces INSTANT PERMANENT exclusion of the coordinator (ExcludedSet, not
a transient park) even when the two proofs are split across two honest observers.

Unlike the existing policy-level test, which uses a SHA-256 fakeVerifier, this
uses a REAL secp256k1 operator-key Signer/Verifier (local_v1), so both packages
must genuinely authenticate under the same verifier the coordinator instance
carries. A non-vacuous negative control -- one authentic package plus one whose
real signature is corrupted (rejected by the real verifier) -- is only one
distinct authentic body and does NOT exclude the coordinator, proving the
verifier is genuinely cryptographic and the positive exclusion required two
authentic distinct bodies. Every snapshot carries no reject/conflict/overflow
evidence, pinning causation to the equivocation path rather than an f+1 tally.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…retry #3c)

A member that floods a receive loop faster than it drains genuinely overflows
the bounded inbound channel, and that real recorded overflow evidence -- carried
by an f+1 quorum of honest observers -- drives a TRANSIENT PARK of the flooder
in the next attempt (transport pressure costs one attempt of liveness, then the
member rejoins), NOT a permanent exclusion.

Closes the gap where the overflow primitive (enqueueOrRecordOverflow) and the
park policy (next_attempt.go) were only ever tested separately -- the primitive
with synthetic recorder-count assertions, the policy with hand-authored
OverflowEntry bundles. Here the evidence the policy parks on is the exact
evidence the real primitive produced against a real full bounded channel. The
flooder is itself a bundle sender, so silence-parking cannot account for the
park -- only the overflow quorum can. Asserts the fault was actually reached (the
channel rejected enqueues and the recorder recorded overflow), that the park is
transient (a following attempt with no accusations reinstates the flooder), and
that the f+1 quorum is genuinely enforced (a single accuser does not park).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…#4)

Two honest nodes with divergent selection state selecting for the same
committed attempt would broadcast DIFFERENT NextAttempt included sets -- a
ROAST-consumed set vs a legacy shuffle -- the fracture class that splits the
signing group. The test first proves the divergence is real (a registered,
ROAST-active node selects the full 5-member transition set while a would-be
legacy node trims to the honest threshold), then proves the fail-closed guard
collapses that divergence: the SAME node-B Select call that returned a concrete
legacy set with the registry empty FAILS CLOSED once ROAST is active (a wiring
partial-registration), and node A fails closed on its missing expected
transition. Neither emits a NextAttempt set, so they cannot converge on
divergent ones -- the network fails closed instead of splitting.

Closes the gap where the fail-closed branches were only exercised in isolation
with fakes; nothing proved the two configs would actually diverge and that the
guard, not chance, suppresses the divergent legacy selection. The false->true
RoastRetryActive flip on node B's identical call is the proof, and each
fail-closed decision is repeated to show it is a deterministic per-seat function
of registry state. Pure-Go: no FROST rounds, bus, or block timing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…nment)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…out, invalid-share, equivocation, overflow, cross-node fracture) (#4134)

## What

Adds **real-under-failure** ROAST retry/blame tests. Prior coverage was
disjoint: the real-cgo interactive e2es are happy-path only, and the
retry/parking/blame machinery (`next_attempt.go`, the round-2 collector,
the overflow primitive, the cross-node selector guard) is unit-tested
with fakes — nothing wired the real component + an induced fault + its
retry/blame outcome together. Each test asserts the induced fault was
**actually reached** (not merely that the outcome happened), so a
synthetic bundle can't make it pass vacuously.

## The tests

Over the real `pkg/net` transport against the real cgo FROST engine
(`pkg/frost/signing`, `frost_native frost_tbtc_signer cgo`):

- **`..._dropout_retry_...`** (#1) — a *selected* signer withholds its
round-2 share → the elected coordinator (the aggregator) starves on a
real collect-shares timeout → `NextAttempt` **transiently parks** the
silent seat → the reshuffled subset aggregates a real BIP-340 signature
and reaches `Succeeded`. Asserts the coordinator starves *specifically*
at share collection AND the target actually reached round 2 and produced
the share it withheld.
- **`..._invalid_share_exclusion_...`** (#2) — a selected signer submits
a structurally valid but cryptographically **wrong** round-2 share → the
real aggregate fails with a typed share-verification error naming the
culprit → an f+1 reject quorum **permanently excludes** it → the
surviving subset finalizes for real.
- **`..._share_conflict_equivocation_...`** (#3b) — a selected signer
runs round 2, produces a genuine FROST share, then broadcasts **two
body-different signed share submissions** (its real share + a re-signed
copy with a mutated `signature_share`), both binding the authoritative
package so both are *accepted* shares. An honest `Round2Collector` flags
the second as `EquivocationKindShareConflict` (`ErrShareConflict`) and
the process-wide observer receives the culprit-naming evidence. Asserts
the two envelopes are distinct, same-package-bound accepted shares (a
genuine double-sign, not a divergent share).
- **`..._coordinator_equivocation_...`** (#3a) — the elected coordinator
distributes **two VALID coordinator-signed packages** (distinct taproot
roots) for the same attempt → `verifiedCoordinatorEquivocations`
bypasses the f+1 gate and forces **instant permanent exclusion**, even
when the two proofs are split across two observers. Uses a **real
secp256k1 operator-key Signer/Verifier** (not the NoOp pair), with a
non-vacuous negative control: one authentic package + one whose
signature is corrupted (rejected by the real verifier) is only one
distinct authentic body and does **not** exclude — proving the verifier
is genuinely cryptographic.
- **`..._overflow_park_...`** (#3c) — a member floods a receive loop
faster than it drains, genuinely overflowing the bounded inbound channel
via the real `enqueueOrRecordOverflow` primitive → the real recorded
overflow evidence, carried by an f+1 quorum, drives a **transient park**
(not exclusion). Asserts the channel actually rejected enqueues and the
recorder recorded overflow, that the park is transient (a following
attempt reinstates the flooder), and that the f+1 quorum is genuinely
enforced (a single accuser does not park). The flooder is itself a
bundle sender, so silence-parking can't account for the park.

In `pkg/tbtc` (`frost_native frost_roast_retry`, pure-Go):

- **`..._cross_node_fracture_...`** (#4) — two nodes with divergent
selection state would broadcast **different NextAttempt sets** (a
ROAST-consumed set vs a legacy shuffle) — the fracture class that splits
the group. The test proves the divergence is real (registered
ROAST-active node selects the full transition set; a would-be-legacy
node trims to the honest threshold), then proves the **fail-closed
guard** collapses it: the SAME node-B `Select` call that returned a
concrete legacy set with the registry empty fails closed once ROAST is
active, and node A fails closed on its missing expected transition.
Neither emits a set, so they can't converge on divergent ones. Each
fail-closed decision is repeated to show it is deterministic per-seat.

## CI coverage

- #1/#2/#3a/#3b/#3c run under **frost-cgo-integration** (`frost_native
frost_tbtc_signer frost_roast_retry`, linked libfrost_tbtc).
- #4 runs under the **client** `frost_native frost_roast_retry` tag set
over `./pkg/tbtc/...`.

All six are green locally, stable across repeated runs, with no
regression to the existing real-cgo suite.